OpenEdge Data Management:<br />Database Administration PROUTIL TABLEMOVE qualifier

Moves a table and optionally its associated indexes from one storage area to another while the database remains online.

Syntax

Parameters

Specifies the owner of the table containing the data you want to dump. You must specify an owner name unless the table’s name is unique within the database, or the table is owned by PUB. By default, Progress 4GL tables are owned by PUB.

Specifies the area name of the target application data area into which the table is to be moved. Area names with spaces in the name must be quoted, for example, “Area Name.”

Optionally, specifies the name of the target index area. If the target index area is supplied, the indexes will be moved to that area. Otherwise they will be left in their existing location. You can move indexes to an area other than the area to which the table is being moved. Area names with spaces in the name must be quoted, for example, “Area Name.”

Notes

proutil `db-name` -C tablemove [`owner-name`.]`table-name` `table-area` [`index-area`]

If you omit the index-area parameter the indexes associated with the table will not be moved.

Moving the records of a table from one area to another invalidates all the ROWIDs and indexes of the table. Therefore, the indexes are rebuilt automatically by the utility whether you move them or not. You can move the indexes to an application data area other than the one to which you are moving the table. If you want to move only the indexes of a table to a separate application data area, use the PROUTIL IDXMOVE utility.

Moving a table’s indexes with the TABLEMOVE qualifier is more efficient than moving a table separately and then moving the indexes with the IDXMOVE utility. Moving a table separately from its indexes wastes more disk space and causes the indexes to be rebuilt twice, which also takes longer.

The PROUTIL TABLEMOVE utility operates in phases:

Phase 1 — The records are moved to the new area and a new primary key is built.

Phase 2 — All the secondary indexes are built.

If you did not specify the index-area parameter, then the indexes are rebuilt in their original area. If you did specify the index-area parameter, then all the indexes are moved to the new area where they are rebuilt.

Phase 3 — All the records in the old area are removed.

Phase 4 — All the old indexes are killed and the _StorageObject records of the indexes and the table are updated.

Although PROUTIL TABLEMOVE operates in phases, it moves a table and its indexes in a single transaction. To allow a full recovery to occur when a transaction is interrupted, every move and delete of each individual record is logged. As a result, moving a table requires the BI Recovery Area to be several times larger than the combined size of the table and its indexes. Therefore, before moving your table, determine if your available disk capacity is sufficient to support a variable BI extent that might grow to more than three times the size of the table and its indexes.

While you can move tables online, no access to the table or its indexes is recommended during the move. The utility acquires an EXCLUSIVE lock on the table while it is moving. An application that reads the table with an explicit NO-LOCK might be able to read records, but in some cases might get the wrong results, since the table move operation makes many changes to the indexes. Run the utility during a period when the system is relatively idle, or when users are doing work that does not access the table.

No other administrative operation on any index of the moved table is allowed during the table move.

There is a possibility that the utility will have to wait for all the necessary locks to be available before it can start. This might take some time

The _UserStatus virtual system table displays the utility’s progress. For more information, see Chapter 14, " Maintaining Database Structure."